Redis哨兵模式配置详解 |
您所在的位置：网站首页 › redis 哨兵配置详解 › Redis哨兵模式配置详解 |
Redis哨兵模式配置详解
|
主从复制模式，它是属于 Redis 多机运行的基础，但这种模式本身存在一个致命的问题，当主节点奔溃之后，需要人工干预才能恢复 Redis 的正常使用。 我们需要一个自动的工具——Redis Sentinel（哨兵模式）来把手动的过程变成自动的，让 Redis 拥有自动容灾恢复（failover）的能力。 哨兵就相当于对主从服务器做一个监视的任务。一旦发现主服务器宕机了，就迅速启动相应的规则将某一台从服务器升级为主服务器，无需人工干预，更稳定更快。 哨兵模式需要依赖主从复制模式，主从复制模式详解参见我的微博 【Redis主从复制模式配置详解】 哨兵模式结构图如下：
配置哨兵模式的前提是实现了主从复制模式的配置，即一个主服务，2个从服务。 1.1创建哨兵配置文件最少创建三个哨兵，注意哨兵的数量是奇数。 创建哨兵配置文件目录在redis 目录（/usr/local/redis-7.2.4）下，创建一个哨兵配置文件目录 sentinel-conf mkdir sentinel-conf
在redis目录下，拷贝sentinel.conf到sentinel-conf目录下，命名为sentinel-26381.conf cp sentinel.conf sentinel-conf/sentinel-26381.conf修改配置文件sentinel-26381.conf vim sentinel-26381.conf修改项目如下： #修改port port 26381 #开启守护线程 daemonize yes #进程文件 pidfile /var/run/redis-sentinel-26381.pid #sentinel monitor #master-group-name是集群名称，可以自定义， #ip：master主机ip地址 #quorum哨兵数量，是需要同意主节点不可用的Sentinel的数量，一般是哨兵数量减1 #比如2表示，当至少有2个哨兵发现master的redis挂了， # 那么就将此master标记为宕机节点。 # 这个时候就会进行故障的转移，将其中的一个从节点变为master sentinel monitor mymaster 127.0.0.1 6380 2如下图：
修改sentinel-26382.conf： vim sentinel-26382.conf 修改内容同上，如下图： 同样修改sentinel-26383.conf vim sentinel-26383.conf
分别修改vim sentinel-26381.conf、 vim sentinel-26382.conf、 vim sentinel-26383.conf 主要改如下四个配置： # 第三个参数：哨兵名字，可自行修改。（若修改了，那后面涉及到的都得同步） # 第四个参数：master主机ip地址 # 第五个参数：redis端口号 # 第六个参数：哨兵的数量。比如2表示，当至少有2个哨兵发现master的redis挂了， # 那么就将此master标记为宕机节点。 # 这个时候就会进行故障的转移，将其中的一个从节点变为master sentinel monitor mymaster 192.168.101.123 7001 2 # master中redis的密码 sentinel auth-pass mymaster 123456 # 哨兵从master节点宕机后，等待多少时间（毫秒），认定master不可用。 # 默认30s，这里为了测试，改成10s sentinel down-after-milliseconds mymaster 10000 # 当替换主节点后，剩余从节点重新和新master做同步的并行数量，默认为 1 sentinel parallel-syncs mymaster 1 # 主备切换的时间，若在3分钟内没有切换成功，换另一个从节点切换 sentinel failover-timeout mymaster 180000修改结果如下： sentinel-26381.conf
sentinel-26382.conf
sentinel-26383.conf
先关闭redis所有服务
为了在一台主机上模拟启动三个服务，我们在shell开三个窗口，分别启动主从服务 6380、从服务6381、6382，不在后台启动 主服务 6380 redis-server redis-master.conf
从服务1 6381 redis-server /usr/local/redis-7.2.4/redis-conf/redis-slave1.conf
从服务2 6382 redis-server /usr/local/redis-7.2.4/redis-conf/redis-slave2.conf
也是为了模拟测试，启动三个不同的shell 启动哨兵一 26381 为了测试，在配置文件中把守护模式改为 no
如果报如下错误，正常启动请忽略: 7790:X 08 Mar 2024 05:35:43.959 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
这是由于 Redis 容器日志中的警告信息指出了内存超分配（overcommit）的设置问题。在 Linux 系统中，内存超分配是一种内核行为，允许进程分配超出物理内存大小的虚拟内存。对于 Redis，这是一个重要的设置，尤其是当执行如 RDB 快照或 AOF 日志重写等内存密集型操作时。 解决办法： 临时更改（不会在重启后保持）： 在宿主机上执行以下命令： sudo sysctl vm.overcommit_memory=1
永久更改： 编辑 /etc/sysctl.conf 文件（或在某些系统上，可能是 /etc/sysctl.d/ 目录下的文件）。 添加或修改以下行： vm.overcommit_memory = 1 保存文件并重新启动系统，或者运行 sudo sysctl -p 来立即应用更改。 启动后如下：
启动后，主服务6380也可以感知到
启动哨兵二 26382 为了测试，在配置文件中把守护模式改为 no
再启动 redis-sentinel /usr/local/redis-7.2.4/sentinel-conf/sentinel-26382.conf
启动后后，主服务6380也有反应
启动哨兵三26383 redis-sentinel /usr/local/redis-7.2.4/sentinel-conf/sentinel-26383.conf
1.模拟强制关闭主服务redis-master 6380
主服务redis-master 6380已经关闭 2. 30秒后，查看哨兵启动窗口，发现主服务从6380 切换到6381
再看从服务，顺利连到6381
重启启动强制挂掉的6380
再看6381，已经检测到6380已经连接 再重复一遍，如果挂了6381，则6382显示如下：
30秒后，又切换到6380
|
这样就配置成功了。【本文地址】